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Secure media path methods, systems, and architectures 



(57) Methods, systems and architectures ioi 
processing renderable digital content are described. 
The vario us embodiments can protect against unauthor- 
ized access or duplication of unprotected content (i.e. 
decrypted content) once the content has reached a ren- 
dering device such as a user's computer. A flexible 
framework includes an architecture that allows for gen 
eral media sources to provide virtually any type of mul 
timedia content to any suitably configured rendering de- 
vice. Content can be protected and rendered locally 



and/or across networks such as the Internet. The inven- 
tive architecture can allow third parties to write compo- 
nents and for the components to be securely and flexibly 
incorporated into a processing chain. The components 
can be verified by one or more authentieators that are 
created and then used to walk the chain of components 
to verify that the components are trusted. The various 
embodiments can thus provide a standard platform that 
can that can be leveraged to protect content across a 
wide variety of rendering environments, content types 
and DRM techniques. 
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Description 
TECHNICAL FIELD 

[0001 ] This invention relates to methods and systems 
for processing renderable digital data, such as video da- 
ta, audio/video data, and the tike. In particular, the in- 
vention relates to methods and systems for protecting 
digital data. 

BACKGROUND 

[0002] Protecting the ownership of digital content, 
such as multimedia content and the like, and the usage 
rights of authorized users of such content has, in recent 
years, become very important. The importance of pro- 
tecting such content will Inevitably continue to grow as 
the content is more easily distributed, particularly in the 
environment of computing networks such as the Inter- 
net. 

[0003] There are many scenarios that can benefit and 
thrive from content protection techniques. For example, 
movie content providers can more easily sell content di- 
rectly to Individuals when the providers are assured that 
their content wil! be protected. Additionally, users can 
more easily and conveniently receive content from sub- 
scription style services {such as cable providers, pay- 
per-view digitai satellite, and the like). Further, users can 
store and playback content at a later date or make cop- 
ies for themselves, while still ensuring that the content 
owner's rights are still maintained. Additionaliy, users 
can create their own content and know that they can re- 
strict who can view it. For example, a user couid post 
private home videos to a web site and only ailow other 
family members to view it for a limit period of time. 
[0004] When content is provided to a device and 
played for a user, a weil defined architecture (with both 
' software and hardware components) is typicaily re- 
quired to coordinate playback and to ensure that digital 
rights are protected and maintained. Often times pro- 
tected content is transferred to a user's device (e.g. a 
computing device, set top box and the like) from a con- 
tent source such as a video web server or even from a 
local hard drive. The content can typically be encoded 
or compressed and encrypted at the content source. 
Subsequently, the user's device decrypts the content, 
decompresses it, and displays or otherwise renders the 
content for the user on, for example, a monitor and/or 
speakers. 

[0005] Content is typicaliy protected using digital 
rights management (DRM) techniques that continue to 
develop and evolve. DRM techniques typically utilize 
software that enables secure distribution and, perhaps 
more importantly, disables illegal - distribution of paid 
content over a network such as the Web. Current DRM 
efforts have focused primarily on securing audio con- 
tent, However, as the bandwidth of networks increases, 
distributing video directly to end users will become tech- 



nically efficient and feasible. Valuable digital content is 
also now becoming increasingly available through other 
sources such as digital TV, digital cable or via digital me- 
dia. 

[0006] In the future, architectures for enabling a user 
to experience digital content will have to exist that resist 
circumvention and unauthorized access by both users 
and by adversarial entities. At the same time, the archi- 
tectures should be flexible enough to grant legitimate 

> access to any trusted component, should allow new ap- 
plications, software components and hardware devices 
to be used with protected content, work with a variety of 
different types of media, and provide some mechanism 
to authenticate and play content on remote hardware 

> devices such as hand held PDAs, play to remote digital 
speakers, and the like. 

[0007] Architectures also need to be flexible and ab- 
stracted enough so that only the lower infrastructure lay- 
ers are required to be trusted, thereby allowing untrust- 
o ed applications to play protected content without knowl- 
edge of it being protected. 

[0008] Accordingly, this invention arose out of con- 
cerns associated with providing improved methods and 
systems for processing renderable digital data in a man- 
s ner that provides a desirable degree of flexible security. 

SUMMARY 

[0009] Methods, systems and architectures for 

io processing renderable digital content are described. 
The various embodiments can protect against unauthor- 
ized access or duplication of unprotected content (i.e. 
decrypted content) once the content has reached a ren- 
dering device such as a user's computer, A flexible 

J5 framework includes an architecture that allows for gen- 
eral media sources to provide virtually any type of mul- 
timedia content to any suitably configured rendering de- 
vice. Content can be protected and rendered iocaliy 
and/or across networks such as the Internet. 

io [001 0] The inventive architecture can allow third par- 
■ ties to write components and for the components to be 
securely and flexibly incorporated into a processing 
chain. The components can be verified by one or more 
authenticators that are created and then used to walk 

45 the chain of components to verify thatthe components 
are trusted. The various embodiments can thus provide 
a standard platform that can be leveraged to protect 
content across a wide variety of rendering environ- 
ments, content types, and DRM techniques. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0011] 

Fig. 1 is a high level block diagram of a system with- 
in which various inventive principles can be em- 
ployed. 

Fig. 2 is a block diagram of an exemplary computing 
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environment within which principles of the de- 
scribed embodiment can be implemented. 
Fig. 3 is a block diagram that illustrates an exem- 
plary system that can be utilized to implement one 
or more of the embodiments. 
Fig. 3a is a flow diagram that illustrates steps in a 
method in accordance with one embodiment. 
Fig. 4 is a block diagram that illustrates an exem- 
plary system that can be utilized to implement one 
or more of the embodiments. 
Fig. 5 is a block diagram that illustrates aspects of 
an authentication design in accordance with one 
embodiment. 

Fig. 6 is a block diagram that illustrates an exem- 
plary system that can be utilized to implement one 
or more of the embodiments in connection with a 
network environment. 

Fig. 7 is a block diagram that illustrates an exem- 
plary system that can be utilized to implement one 
or more of the embodiments in connection with a 
network environment. 

DETAILED DESCRIPTION 

Overview 

[0012] The methods, systems and architectures de- 
scribed below are directed to providing a protected me- 
dia path from some source of protected content (e.g. a 
DRM server, DVD server (usually a DVD disc drive), 
HDTV server (usually a TV stall on broadcasting to a tun- 
er card a o n a PC) or any particular type of content serv- 
er) to and through a device (including the device's soft- 
ware and hardware) that can render or otherwise play 
the protected content for a user. 
[0013] As an example, consider Fig. 1 . There, a sys- 
tem 1 00 includes a number of different types of protect- 
ed content sources or providers such as a DVD server 
1 02, a content server 1 04 (such as one that can provide 
audio content, audio/video content, and the like), HDTV 
server 106, and a local hard disk 116, to name just a 
few. The content providers are configured to provide 
their content over various mediums that can include net- 
works such as networks 108, 110, 112, 118, busses 
(such as PC I an d AGP busses ) and the like. The content 
is typically provided to some type of device that can 
present the content to a user. Exemplary devices in- 
clude, without limitation, a personal computer 114, 
handheld PC 120, television 122 with, for example, a 
set top box 1 24, and the like. 

[0014] In thediscussion thatappears below, the target 
h ardware for such content is , in o n e emb odiment, a local 
PC with a protected video card on it, and in other em- 
bodiments, a remote handheld device such as a hand- 
held computer. It Is to be appreciated and understood 
that such examples are intended to illustrate but a few 
exemplary environments in which the inventive princi- 
ples described herein can be employed. Accordingly, 



other types of devices can be employed without depart- 
ing from the spirit and scope of the cl aimed subject mat- 
ter. 

[0015] The methods, systems and architectures de- 
5 sen bed below can be directed to handling different types 
of content formats, many of which can have specific 
DRW (digital rights management) characteristics which 
can Include, in many instances, their own rights man- 
agement and encryption. This can greatly increase the 
10 flexibility and robustness with which content can be pro- 
tected. Accordingly, having a flexible architecture can 
avoid a situation where all content must necessarily be 
tied to one particular type of DRM format. Hence, in one 
or more of the embodiments described below, one ad- 
's varttageous feature of the architecture is that third par- 
ties can write and provide translator modules that can 
be imported into the architecture, and then used to map 
into a common rights management and encryption sys- 
tem that can ensure that architectural components are 
20 trusted and verified. 

[0016] In addition, the embodiments described below 
can embody one or more of the following features and/ 
or advantages. An authenticator mechanism is provided 
and can be generalized into a recursive algorithm that 
SB follows the flow of data. In some embodiments, an initial 
authenticator is provided and begins authenticating the 
chain of components that will handle protected data. Ad- 
ditional authenticators can be created along the chain 
and can establish a secure channel through which they 
so can communicate. The authenticators need not initially 
have knowledge of the structure of the data graph In or- 
der to perform their authentication duties. Various em- 
bodiments can make use of revocation lists that can pre- 
vent the use of known components that have been com- 
as promised. Further, in some embodiments, direct au- 
thentication oi hardware and encryption to hardware de- 
vices is possible. Various embodiments can be config- 
ured to work with untrusted applications. In this case, 
data can be protected from the untrusted application. 
to yet can still be processed by the component chain by 
trusted and verified components. Authorized applica- 
tions, such as those that are trusted, can be granted ac- 
cess to the data, This is useful for enabling applications 
to manipulate data as by performing visualizations or 
« mod iflcations to the data. 

[0017] Various embodiments can be implemented in 
connection with remote devices that can render data 
over various buses, networks and the like, with full au- 
thentication and encryption support. This can allow a 
SO host to perform most of the preprocessing and interface 
control so that the remote device (e.g. a PDA) can sim- 
ply display the data. Additionally, various embodiments 
can process protected content from a variety of sources. 
That is, protected content can be produced by both local 
55 devices (e.g. DVD drive, video cameras, TV tuners, dig- " 
ital cable) and remote sources (such as a web or video 
server). Further, data processing chains can be re-used 
within other data processing, chains. For example, al- 
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most al! of the components used to playback secure au- 
dio can be reused to protect the audio track from a video 
clip. 

[0018] These and other advantages will become ap- 
parent in light of the discussion that follows. 
[001 9] The embodiments can process any stream of 
data an d are not specifically bound to only video or audio 
data. Thus, the embodiments can be used to protect oth- 
er data formats. 

Exemplary Computing System 

[0020] Fig. 2 illustrates an example of a suitable com- 
puting environment 200 on which the system and relat- 
ed methods described below can be implemented. 
[0021] It is to be appreciated that computing environ- 
ment 200 is only one example of a suitable computing 
environment and is not intended to suggest any limita- 
tion as to the scope of use or functionality of the media 
processing system. Neither should the computing envi- 
ronment 200 be interpreted as having any dependency 
or requirement relating to any one or. combination of 
components illustrated in the exemplary computing en- 
vironment 200. 

[0022] The various described embodiments can be 
operational with numerous other general purpose or 
special purpose computing system environments or 
configurations. Examples of well known computing sys- 
tems, environments, and/or configurations that may be 
suitable for use with the media processing system in- 
clude, but are not limited to, personal computers, server 
computers, thin clients, thick clients, hand-held or laptop 
devices, multiprocessor systems, microprocessor- 
based systems, set top boxes, programmable consum- 
er electronics, network PCs, minicomputers, mainframe 
computers, distributed computing environments that in- 
clude any of the above systems or devices, and the like. 
[0023] in certain implementations, the system and re- 
lated methods may well be described in the general con- 
text of computer-executable instructions, such as pro- 
gram modules, being executed by a computer. Gener- 
ally, program modules include routines, programs, ob- 
jects, components', data structures, etc. that perform 
particular tasks or implement particular abstract data 
types. The embodiments can also be practiced in dis- 
tributed computing environments where tasks are per- 
formed by remote processing devices that are linked 
through a communications network. In a distributed 
computing environment, program modules may be lo- 
cated in both local and remote computer storage media 
including memory storage devices. 
[0024] In accordance with the illustrated example em- 
bodiment of Fig. 2, computing system 200 is shown 
comprising one or more processors or processing units 
202, a system memory 204, and a bus 206 that couples 
various system components including the' system' mem- 
ory 204 to the processor 202. 

[002S] Bus 206 is intended to represent one or more 



of any of several types of bus structures, Including a 
memory bus or memory controller, a peripheral bus, an 
accelerated graphics port, and a processor or local bus 
using any of a variety of bus architectures. By way of 

5 example, and not limitation, such architectures include 
Industry Standard Architecture (ISA) bus, Micro Chan- 
nel Architecture (MCA) bus, Enhanced ISA (EISA) bus, 
Video Electronics Standards Association (VESA) local 
bus, and Peripheral Component Interconnects (PCI) 

10 bus also known as Mezzanine bus. 

[0026] Computer 200 typically Includes a variety of 
computer readable media. Such media may be any 
available media that is locally and/or remotely accessi- 
ble by computer 200, and it Includes both volatile and 

is non-voiattle media, removable and non-removable me- 
dia. 

[0027] In Fig. 2, the system memory 204 includes 
computer readable media in the form of volatile, such 
as random access memory (RAM) 210, and/or non-vol- 

so atile memory, such as read only memory (ROM) 208. A 
basic input/output system (BIOS) 212, containing the 
basic routines that help to transfer information between 
elements within computer 200, such as during start-up, 
is stored in ROM 208. RAM 210 typically contains data 

2$ and/or program modules that are immediately accessi- 
ble to and/or presently be operated on by processing 
unit(s) 202. 

[0028] Computer 200 may further include other re- 
movable/non-removable, volatiie/non-volatile computer 
30 storage media. By way of example only, Fig . 2 illustrates 
a hard disk drive 228 for reading from and writing to a 
non-removable, non-volatile magnetic media (not 
shown and typically called a "hard drive"), a magnetic 
disk drive 230 for reading from and writing to a remov- 
es able, non-volatile magnetic disk 232 (e.g., a 'floppy 
disk"), and an optical disk drive 234 tor reading from or 
writing to a removable, non-volatile optical disk 236 such 
as a CD-ROM, DVD-ROM or other optical media. The 
hard disk drive 22B, magn etic disk drive 230 , and optical 
to disk drive 234 are each connected to bus 206 by one or 
more interfaces 226. 

[0029] The drives and their associated computer- 
readable media provide nonvolatile storage of computer 
readable instructions, data structures, program mod- 

45 ules, and other data for computer 200, Although the ex- 
emplary environment described herein employs a hard 
disk 226, a removable magnetic disk 232 and a remov- 
able optical disk 238, it should be appreciated by those 
skilled in the art that other types of computer readable 

so media which can store data that is accessible by a com- 
puter, such as magnetic cassettes, flash memory cards, 
digital video disks, random access memories (RAMs), 
read only memories (ROM), and the like, may also be 
used in the exemplary operating environment. 

55 [0030] A number of program modules may be stored 
on the hard disk 228, magnetic disk 232, optical disk 
236, ROM 208, or RAM 21 0, Including, by way of exam- 
ple, and not limitation, an operating system 214, one or 
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more application programs 21 6 (e.g., multimedia appli- 
cation program 224), other program modules 218, and 
program data 220. A user may enter commands and in- 
formation into computer 200 through input devices such 
as keyboard 23B and pointing device 240 (such as a 
"mouse"). Other input devices may include a audio/vid- 
eo input device(s) 253, a microphone, joystick, game 
pad, sateilite dish, serial port, scanner, or the like (not 
shown). These and other input devices are connected 
to the processing unit(s) 202 through input interface(s) 
242 that is coupled to bus 206, but may be connected 
by other interface and bus structures, such as a parallel 
port, game port, or a universal serial bus (USB). 
[0031) . A monitor 256 or other type of display device 
is also connected to bus 206 via an interface, such as 
a video adapter or video/graphics card 244. in addition 
to the monitor, personal computers typically include oth- 
er peripheral output devices (not shown), such as 
speakers and printers, which may be connectedthrough 
output peripheral Interface 246. 
[0032} Computer 200 may operate in a networked en- 
vironment using logical connections to one or more re- 
mote computers, such as a remote computer 250, Re- 
mote computer 250 may include many or all of the ele- 
ments and features described herein relative to compu- 
ter. 

[0033] As shown in Fig. 2, computing system 200 is 
communicatively coupled to remote devices (e.g., re- 
mote computer 250) through a local area network (LAN) 
251 and a general wide area network (WAN) 252. Such 
networking environments are commonpiace in offices, 
enterprise-wide computer networks, intranets, and the 
Internet, 

[0034] When used in a LAN networking environment, 
the computer 200 is connected to LAN 251 through a 
suitable network interface or adapter 248. When used 
in a WAN networking environment, the computer 200 
typically includes a modem 254 or other means for es- 
tablishing communications over the WAN 252. The mo- 
dem 254, which may be internal or external, may be con- 
nected to the system bus 206 via the user input interface 
242, or other appropriate mechanism. 
[0035] In a networked environment, program modules 
depicted relative to the personal computer 200, or por- 
tions thereof, may be stored in a remote memory stor- 
age device. By way of example, and not limitation, Fig, 
2 illustrates remote application programs 216 as resid- 
ing on a memory device of remote computer 250. It will 
be appreciated that the network connections shown and 
described are exemplary and other means of establish- 
ing a communications link between the computers may 
be used. 

Exemplary Embodiments 

[0036] Fig. 3 illustrates an exemplaiy chain of compo- 
nents that is useful In understanding various inventive 
principles described herein. One overall goal of the Fig. 



3 system is to be able to receive encrypted data or con- 
tent, and DRM data from some source or sources, map 
the data into a common system, and then be able to 
have a license specify that the data or content requires 

s a protected media path. Subsequently, the system 
should be able to verify that the system's components 
that make up the media path are trusted. One aspect of 
the described embodiments is that the architecture can 
facilitate handling many different types of data formats 

'£> and can be employed in the context of many different 
types of components. That is, the architecture does not 
need to be inextricably tied to any specific components 
for effectively being able to process and render protect- 
ed content, 

[0037] The discussion that follows provides some- 
what of a high level, functional overview of a system that 
embodies various inventive principles in accordance 
with one embodiment. More detailed aspects of an ex- 
emplary system are described in the section entitled 
20 "Implementation Example - Local Device Embodiment" 
below. 

[0038] The Illustrated system can effectively be bro- 
ken down into six stages for purposes of understanding 
various inventive principles, each of which Is discussed 
& In more detail below: 

• A content source component and its connection to 
a license server (e.g. content source 300); 

• A client component and associated components to 
30 decrypt the data and process content manifests that 

contain DRM content (e.g. client 304); 

• A demultiplexer, decoders and data re-encryptors 
(e.g. demultiplexer 306, decoder 308, and encryp- 
ted 10); 

35 • An application for processing and mixing data 
streams (e.g. application 312); 

• One or more Tenderers that set up hardware de- 
cryption and schedule the display of the data (e.g. 
Tenderer .314); and 

40 . Hardware for decrypting and rendering the data (e. 
g. rendering hardware 31 6). 

[0039] In addition to the above-iisted stages, the illus- 
trated system also makes use of multiple different au- 

15 thenticators that are created during a verification proc- 
ess to effectively confirm that components that make up 
the system are trusted. This can be done by verifying 
digital signatures that are embodied on the components. 
In this example, there are three authenticators— a pri- 

so mary authenticator 31 8, and two secondary authentica- 
tors 320, 322. Notice that authenticators 318 and 320 
are user mode authenticators and accordingly, are used 
to verify user mode components. Authenticator 322, on 
the other hand, is a kernel mode authenticator and is 

55 used to verify kernel mode components. 

[0040] Further, the system can employ a translator 
such as translator 302. Translator 302 can be used to 
translate content and license data from one DRM format 
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into one that is understood by the system. That is, one 
of the advantages of the system about to be described 
is that the system can be configured to work in connec- 
tion with different so-cafled "foreign" DRM formats that 
the system does not natively understand. Specifically, 
translator components can be written by, for example, 
third parties, that enable different diverse DRM formats 
to be employed with a common architecture. That way, 
the system can be imparted with a degree of flexibility 
that stretches across a wide variety of known or subse- 
quently developed DRM formats. 

Content Source 

[0041] lnthisparticu!arexample,contentsourcecom- 
ponents, such as content source 300, are responsible 
for reading any native DRM sources (i.e. sources that it 
understands) or translating foreign DRM formats into a 
DRM format that it understands. The latter task can be 
accomplished with the help of translator 302 which may 
or may not comprise part of the content source. The 
translator 302 can be used to transcrypt the co ntent and 
license into an understandable DRM format. 
[0042] Local devices that provide DRM content (such 
as a DTV receiver) can translate the encryption system 
and license restrictions into an understandable DRM 
format. A driver associated with such devices can be 
issued a signature to be able to create the DRM content. 
Its license can then specify a dependency on a remote 
licensing server so that revocation lists can be updated. 
Revocation lists can typically be provided to enable the 
system to ascertain which components have been com- 
promised. For example, a license may require a weekly 
revocation ilst which could be locally cached. 

Client and Authenticate rs 



[0043} Client 304 typically receives encrypted content 
and a license that can be included as part of a manifest 
that the client receives. The manifest can typically de- 
scribe the components of a rendering pipeline that are 
necessary for rendering the content. The license can al- 
so include additional information such as the level of se- 
curity that the content requires. This is discussed in ad- 
ditional detail below. 

[0044] The manifest can also indicate the type of au- 
thenticators that are required to be used for verifying 
components in the rendering pipeline. Alternatively, the 
manifest can requirecertaintypes of authenticators, and 
can then rely on the other pipeline components, such as 
the renderers, to create corresponding authenticators, 
such as an audio and video kernel authenticator. 
[0045] After setting up a network connection or cap- 
ture source, the content source can instruct client 304 
to bind according to the license. The content source can 
also set up any source related information for use by the 
client or other components to assist in the binding proc- 
ess. When the license is bound, the client can create 



one or more authenticators (e.g. video and audio au- 
thenticator) such as authenticator 318. The client can 
pass license requirements to the authenticator when it 
is instantiated. 

s [0046] The authenticator(s) can then "walk" through ' 
the components in the pipeline to verify signatures of 
components that handle unencrypted data. For exam- 
ple, in the illustrated system, client 304 can be authen- 
ticated by a secure server after which the client can cre- 

10 ate authenticator 318. Once created, authenticator 31 8 
can verify that demultiplexer 306, decoder 308 and en- 
cryptor are all trusted. 

[0047] Additionally, in this example, whenever data is 
passed overa bus, or between unauthenticated compo- 
nents (using, for example, encrypted Sinks), ortothe ker- 
ne! space, a secondary authenticator can be created to 
verify the remainder of the data flow pipeline. Hence, in 
this example, renderer 314 can create a secondary au- 
thenticator 320 that then verifies that the renderer is 

zo trusted. Authenticators 31 8, 320 can then set up an au- 
thenticated, encrypted channel 319 between them. 
[0048] The authenticated encrypted channel 319 can 
be used for a number of different purposes, For exam- 
ple, the channel can allow communication between ad- 

2s jacent authenticators. This can, for example, allow the 
secondary authenticators to report back verification in- 
formation and validation or other requests to the original 
authenticator. Additionally, the authenticators should be 
able to check revocation lists that describe components 

30 that have been compromised and can thus no longer be 
trusted. Further, the authenticated, encrypted channel 
can be used to set up encryption sessions for encrypting 
video and audio data between the trusted components. 
[0049] On a remote rendering device with hardware 

35 decryption support (such as that which'is described be- 
low in more detail), a secondary authenticator can be 
created to proxy encryption and authentication to the re- 
mote device. Only a small, possibly untrusted, proxy 
component need be provided on the remote device. The 

40 remote hardware should, then, stilS identify itself so that 
it can be revoked by the primary authenticator. 
[0050] For video content, a generic audio-video (AV) 
authenticator can verify the user mode components and 
the renderer can create media specific authenticators. 

■45 

Demultiplexer. Decoder s, and Re-encryptors 

[0051] Demultiplexer 306 typically receives unen- 
crypted data from client 304 and splits the data into dif- 

50 f erent streams , such as a n audio and video stream . The 
demultiplexer 306 then typically passes the streams to 
one or more decoders, such as decoder 308, for further 
processing. An audio decoder (along with an encryptor 
such as encryptor 31 0) can re-encrypt the data and pro- 

55 vide it to an application 312 for processing. A video de- 
. coder can re-encrypt the data so that it can be securely 
transferred over a PCI/AGP bus into a video card's ran- 
dom access memory (VRAM). The video decoder can 
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typically pass partially compressed {and encrypted) da- , 
tato the video card and can perform timestamp modifi- 
cations, data re-arrangement and header parsing. For 
example, for DVD playback, the decoder can extract the 
vector level data and residuals and pass them to the vid- 
eo hardware for processing. The decoder can also per- 
form any modifications to simulate reverse playback or 
variable speed effects, 

Application and Mixing 

[0052] Application 312 can mix the video and audio 
streams into mixing buffers supplied by the rendererfs). 
The hardware, then, is effectively passed encrypted 
buffers from the decoder along with lists of mixing in- 
structions. A large, number of image processing opera- 
tions and non-linear video effects are possible, as by 
using pixel shaders and arbitrary polygon mappings. If 
the application requires access to unencrypted data, it 
can create a separated trusted worker process. The ap- 
plication then effectively becomes another authenticat- 
ed decoder and will have to decrypt the data, process it 
and re-encrypt it for output to the video hardware or the 
next processing unit. 

Renderers and Compositors 

{0053] In this example, the renderers, such as Tender- 
er 31 4, can proxy the encryption sessions from the de- 
coder 308 to the display and audio driver (i.e. the ren- 
dering hardware316). The renderers are responsible for 
synchronization and hardware setup. The renderer can 
comprise various user mode APis and code, as well as 
the. associated operating system and driver APIs. 
[0054] Once the data has been transferred to the vid- 
eo card's VRAM , it can possibly be decrypted and bl end- 
ed with other video sources then copied to a portion of 
memory (referred to as the "desktop" or "primary sur- . 
face") that is mapped directly to a display for the user. 
The protected media path system described above and 
below should ensure that both temporary mixing buffers 
and the desktop are protecled from unauthorized ac- 
cess. 

[0055] One way of maintaining the integrity of data 
once it is on the desktop is to use trusted graphics hard- 
ware. An exemplary system is described in the following 
patent applications, the disclosures of which are incor- 
porated by reference: "Systems and Methods For Se- 
curing Video Card Output", naming as inventors, Glenn 
Evans and Paul England, bearing Attorney Docket 
Number ms1-1115us, filed on June 24, 2002; "Methods 
and Systems Providing Per Pixel Functionality", naming 
as inventors, Glenn Evans and Paul England, bearing 
Attorney Docket Number ms1-1025u fiied on June 24, 
2002. 

[0056] Essentially, inthe systems described in the ref- 
erenced patent applications, output data is encrypted 
relative to a window's origin on the display. When a win- 



dow is physically moved, either the origin is moved, or 
the data is encrypted relative to the new origin. Only the 
display hardware's DAC is capable of decrypting and 
displaying the data. 
£ [0057) The content can be directly encrypted to the 
desktop by the decoder, or transcrypted using trusted 
hardware by the renderer once the final image has been 
assembled. 

[0058] In embodiments where renderers run over a 
10 network to a "light" client, the renderers can be broken 
into an authenticated local component and a remote 
component, Compressed encrypted data and manipu- 
lation instructions can be sent over the network to the 
remote renderer. Blending data can be performed on the 
*s host should there be no remote hardware support. 

Hardware for Rendering 

[0059] The graphics card is responsible for decry pting 

so the content stream, manipulating the data using a 
graphics processor unit (GPU) and displaying the output 
data. The patent applications Incorporated by reference 
above d escribe one trusted hardware configuration th at 
can be utilized to process protected content. 

ss [0060] In summary, those applications describe cryp- 
tographic support that can be broken into a decryption/ 
encryption engine in the GPU and a component that 
manages the keys (referred to as the "crypto-proces- 
sor").-The graphics h ardware can have per-pixel encryp- 

so tion support so that the VRAM can be maintained in an 
encrypted form. Each graphics operation by the GPU 
can then decrypt the pixel of interest, process it in some 
manner, and re-encrypt the output. The images can be 
tiled with' encryption keys so that each key region will 

35 efficiently match the caches within the GPU. The output 
of the video DAC can provide either digital protection or 
analog protection. For remote displays, the display 
hardware can be imparted with some form of decryption 
support to decrypt the data sent over the network. 

« [0061] Fig. 3a is a flow diagram that describes steps 
in a method in accordance with one embodiment. The 
steps can be implemented in any suitable hardware, 
software, firmware, or combination thereof, in the illus- 
trated example, the steps can be implemented in con- 

& nectlon with a software architecture such as that which 
is described above and below. 

[0062] Step 364 determines whethertranslation of the 
DRM is necessary. If so, step 356 can translate the DRM 
into aform that is understood by the processing system 

so that is to render the content. This step can be accom- 
plished with a separate translator module that can, In 
some inslances, besupplied by third party software ven- 
dors. Step 350 receives encrypted content that is to be 
protected during a rendering process. The content is to 

ss be protected in accordance with a DRM scheme. The 
content can be received from any suitable source, ex- 
amples of which are given above. Step 352 receives a 
manifest associated with the content. Steps 350 and 



BNSDOCtO: <£P_ )37«302A?J_> 



13 



EP 1 376 302 A2 



14 



352 can be performed by a suitably configured client, 
such as client 304 (Fig. 3). The manifest describes pro- 
tected media path requirements that circumscribe the 
process by which the content is to be rendered. Such 
requirements can and typically do come in the form of 
a license. The manifest may or may not be received con- 
temporaneously with the encrypted content. 
[0063] Continuing, step 358 verifies that the client 
component that receives the encrypted content is trust- 
ed. This step can be implemented by a secure server 
that can, for example, verify a digital signature that is 
associated with the client. Step 360 creates a primary 
authenticator. This step can be implemented by the cli- 
ent. Step 362 articulates one or more downstream 
processing stream components to the primary authen- 
ticator. This step can be implemented by the client and/ 
or any of the downstream components. In one embodi- 
ment, the primary authenticator queries the client as to 
the components that it passes data to, and then queries 
those components and so on. Step 384 authenticates 
one or more downstream components with the primary 
authenticator. This step can be implemented by verify- 
ing digital signatures associated with the various com- 
ponents by, for example, using a secure server. 
[0064] Step 366 determines whether any secondary 
authenticators are needed. A secondary authenticator 
can be needed for any suitable reason, exampies of 
which are given below. If secondary authenticators are 
not needed, step 368 does not create one. If, on the oth- 
er hand, a secondary authenticator is needed, step 370 
creates a secondary authenticator and establishes a se- 
cure channel between the authenticators. Step372 then 
uses the secondary authenticator to authenticate one or 
more downstream components. The method can then 
branch back to step 386 to determine whether any ad- 
ditional secondary authenticators are needed. 

Implementation Example - (Local Device 
Embodiment ) 



[0065] Fig. 4 shows an exemplary system that is con- 
figured to process protected media in accordance with 
one embodiment. The system is similar, in some re- 
spects, to the system shown and described in Fig. 3. In 
this particular example, the system is configured to proc- 
ess audio/video data on a local device. Suitable local 
devices can include a local PC, set top box, or any de- 
vice that typically processes audio/video data. 
[0066] The Fig. 4 system includes a video path and 
an audio path. The video path is comprised of a chain 
of components (e.g. parsing and transform compo- 
nents), both user mode and kernel mode, that produce 
video that is placed into a video card's VRAM . The frame 
buffer Is displayed onto the desktop and sent to an out- 
put device through the DAC. An audio path is also pro- 
vided for processing the audio stream. 
[0067] The Fig. 4 system includes a content source 
400 that provides protected content. Such content, as 



noted above, can typically be accompanied by or asso- 
ciated with a license, often included within a manifest. 
The license typicaily circumscribes the content's use by 
describing such things as who can use the content and 

s how it is to be used. The license can also specify such 
things as revocation lists that are to be used in conjunc- 
tion with the content, the frequency of use of such rev- 
ocation lists, and the source of the revocation list such 
as a secure server. The manifest can also typically da- 

10 scribe the level of security that is to be used with the 
protected content such as the nature of the protected 
media path that is to be set up, the identification of com- 
ponents along that media path, and any encryption/de- 
cryption requirements. Note also that a translator can 

*5 typically be employed to translate foreign DRM content 
into DRM content that is understood by the system. 
[0068] The content is provided by the content source 
to a client 404. As noted above, the licensethatthe client 
gets indicates that the data requires a protected media 

20 path authenticator such as authenticator 41 8. In this ex- 
ample, a single client 404 decrypts the data that is re- 
ceived from the content source. Authenticalors, such as 
authenticators 418, 420, and 422 are used to verify the 
chain of components that receive unencrypted data. 

25 This can be done a number of different ways such as 
verifying digital signatures associated with the compo- 
nents and/or though lists of DLL addresses. After a 
processing chain of components has been set up, a 
. server, such as a DRM server, authenticates client 404. 

30 Client 404 th en creates primary authenticator 418 which 
then locates components that process data including 
decrypted data. The components can be located by au- 
thenticator 41 8 by querying individual components as to 
which other components they pass data to. For exam- 

ss pie, authenticator 418 can query client 404 for which 
components the client provides data to. The client can 
respond to the authenticator by Indicating that it passes 
data to demux 406. This can be done by passing a point- 
er to the authenticator that points to the demux 406. 

40 Since the demux 406 processes unencrypted data, it will 
need to be trusted. The demux 406 takes data that is 
u nencry pted by the cl ient and demultiplexes the data in- 
to a video stream and an audio stream. The video 
stream is processed by the video decoder 408a and its 

45 associated downstream components (i.e. encryptor 
410a, video renderer 414a, video driver and GPU (col- 
lectively designated at 41 6a)), while the audio stream is 
processed by the audio decoder 408b and its down- 
stream components (i.e. encryptor 4 10b, audio renderer 

so 414b, audio driver and audio hardware (collectively des- 
ignated at 41 6b)). 

[0069] I ndi vid u al components in the processing chain 
provide addresses, to the authenticators, of other com- 
ponents that they pass unencrypted data to. The au- 
$5 then ticator then walks along the list of components and 
verifies the signatures of components as by, for exam- 
ple, verifying the signatures of the components' corre- 
sponding DLLs. This can be done using a secure server. 
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So, for example, authenticator 41 8 will authenticate de- 
mux 406. The authenticator 41 6 will then verify both de- 
coders 403a, 408b, After learning ttie components to 
which the decoders pass data, (i.e. encryptors 410a, 
410b), the authenticator 418 will authenticate the en- 
cryptors. Application 412 may or may not be a trusted 
application. If the application is to handle unencrypted 
data, then authenticator41 8 can verify that the applica- 
tion is trusted, if the application is not trusted, then it win 
simply handle encrypted data. 
[0070] Eventually, the data will be passed to Tender- 
ers 41 4a, 41 4b. The Tenderers can create thetr own au- 
thenticator 420 which is then verified by authenticator 
41 8. An authenticated, encrypted channel can be estab- 
lished between authenticators 41 8, 420. Once verified, 
authenticator 420 can authenticate the Tenderers. 
[0071] In this example, a kernel mode authenticator 
422 is created by the renderer{s) and is authenticated 
by one or more of the other authenticators. Authentica- 
tor 422 can be securely linked to the user mode authen- 
ticators to verify kernel components, such as compo- 
nents 416a, 416b, 

[0072] A key manager 424 Is also provided and can 
be authenticated by authenticator 422. The key manag- 
er 424 can be responsible for managing encryption/de- 
cryption keys that are used by the various components 
in the processing chain to pass encrypted data. The key 
manager can also manage session keys that are used 
in the encryption process. Custom encryption methods 
can also be used and implemented, in part, by the key 
manager. A replaceable encryption library can, for ex- 
ample, be provided to intermediate components. All 
keys should be session-based keys to avoid having 
keys embeddedinthevarious components. A public key 
encryption algorithm can be used for authentication and 
to setup the session keys between the decoder and a 
crypto processor on the video hardware. The encrypted 
channel used for the authentication can be reused by 
the authenticated components to setup the session 
keys.. This ensures that the decryption key is only 
passed to the entity verified by the next authenticator. if 
a component does not route the encrypted data and the 
authenticated data channel to the same destination, 
then the data stream cannot be decrypted by the down- 
stream entity. The algorithm used to setup the session 
keys can be specific to the decoder and the rendering 
components. The authentication channel can be per- 
sonalized to the session key generation thread to avoid 
spoofing the session key setup. 
[0073] Each component can be, and should periodi- 
cally be re-authenticated and keys should be renegoti- 
ated to help to minimize insertion attacks by foreign 
components. An array of session keys can allow the 
source to efficiently change keys at given intervals, 
Since setting up keys can be a relatively slow and costly 
process, it can be performed asynchronously tothe data 
stream. Cycling through banks of keys can help to avoid 
data-key synchronization issues. For example, four 



keys can provide a four frame delay before a new key 
negotiation would have to be completed. This is dis- 
cussed in more detail below in the section entitled "Key 
Negotiation and Synchronization". 

Key Negotiation and Synchronization 

[0074] Key banks typically contain multiple keys. In 
the video context, as the video renderer processes data, 

io it typically queues up a number of frames for display. 
For efficiency reasons, using a key bank with multiple 
keys and synchronizing, for exampie, one key per 
frame, can alleviate problems associated with having to 
negotiate a new key for each frame. That is, having a 

1$ key bank can reduce the key negotiation time by virtue 
of the fact that negotiation does not have to take place 
on a key-for-key basis . Thus , by using a bank of m ultiple 
keys, one key can be used per frame, and the keys can 
be cycled through in order. For example, keys 1 to 4 

20 might be negotiated, where key 1 is used for frame 1 , 
key 2 is used for frame 2, and so on. Thus, instead of 
having to negotiate for individual keys, negotiation take 
place for multiple keys at a time which are then cycled 
through. 

ss [0075] As an example, in a protected video path, an 
array of session keys can be established between the 
decoder and video hardware using an authenticated PKi 
encryption system. Keys can then be maintained in in- 
accessible memory on the video card and in protected 

30 memory by the decoder. Each key can be referenced by 
session index. In the video hardware, data can be as- 
sociated with a session index or ID that indicates which 
. sessionwasusedtoencryptthedata.Triesession index 
can be used by the GPU to set up the cryptographic en- 

35 glne in the GPU that can then process (i.e. decrypt) the 
encrypted data. The authenticator chain can be period- 
ically renegotialed and authenticated to help reduce dic- 
tionary attacks and to attempt to detect inserted foreign 
components. 

40 

Authenticators 

[0076] As noted above, after the playback mechanism 
(i.e. processing chain) has been set up, the client com- 

45 ponent decrypts the data and passes the data to the vid- 
eo and audio demultiplexer. As part of the auth entication 
process, the client creates an authenticator which is 
then applied to the demultiplexers. The authenticator is 
then directed to the next video and audio, processing 

so components for authentication. The renderers can then 
create corresponding video/audio specific kernel au- 
thenticators. The authenticators can authenticate the 
digital signatures associated with the DLL at which each 
address is located. 

ss [0077] Theauthenticatorscannotonlyverifythecom- 
ponents' signatures, but they can also verify that the . 
processing chain has sufficient security to satisfy the re- 
quirements in the content's license. Far example, the 
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license may specify a level of security is required of the 
processing chain. The security level can be passed to 
the authenUcator which can then ensure compliance 
with the security level. Alternatively, the security level 
can be implicitly encoded by requiring a particular level 
of authenticator, e.g. level 1 authenticator or level 2 au- 
thenticator, both of which cart invoke the primary au- 
thenticator with their level. 
[0078] Exemplary security levels can include: 

• Bit 0 - software obfuscation of compressed data 
(and signed video driver) ; 

• Bit 1 - trusted software protection of compressed 
data; 

• Bit 2 - hardware protection of compressed data over 
buses; 

• Bit 3 - hardware protection of compressed data in 
the video/audio device; 

• Bit 4 - analog protection of data leaving the output 
device; and 

• Bit 5 - digital protection of data leaving the output 
device 

[0079J Each component can also have the ability to 
add restrictions to the license as a first pass in the au- 
thentication. This can allow components (e.g. decoders) 
to require other components to be interrogated for com- 
patibility. For example, an audio decoder may only be 
licensed to be played with applications that meet certain 
criteria. 

[0080] An additional system version requirement can 
also be useful for specifying a required level of driver 
support. For example, the license can contain a data 
pair (minimum protected patNdriver level, minimum 
hardware requirements) that is passed to the authenti- 
cator to ensure compliance. 

Components 

[0081] Various arrangements of authenticates can 
be used to implement the above-described embodi- 
ments. For example, in the system shown anddescribed 
in Fig. 4, there can be two separate primary authentica- 
tors — one for the video chain and one for the audio 
chain, or, as shown in Fig. 4, a single primary authenti- 
cator that communicates with both the audio and video 
chain, in addition, there can be two separate kernel 
mode authenticators- one for the video chain and one 
fortheaudio chain. If this is the case, then two separate 
authenticated, encrypted channels can be provid- 
ed—one each between the authenticators of the audio 
chain and video chain. 

[0082] In the discussion below, one specific authenti- 
cation design is described. It is to be appreciated that 
the described design is illustrative of but one authenti- 
cation design. Accordingly, other authentication designs 
can be provided without departing from the spirit and 
scope of the claimed subject matter. 
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[0083] Fig. 5 illustrates an exemplary authentication 
design where authenticators are designated as "A n ", 
and interfaces supported by various components in the 
processing chain are illustrated as either "iA" for an au- 

s thenticable interface and/or "!AP" for an authentication 
proxy interface. A proxy interface acts as an interface to 
a forwarding service to another authenticabie interface. 
The names of the various components are provided ad- 
jacent the corresponding component, For example, in 

io the audio chain, the audio decoder, audio encoder, ap- 
plication, audio Tenderer and audio driver/hardware are 
indicated, Similarly, in the video chain, the video decod- 
er, video encoder, application, video renderer and video 
driver/hardware are indicated. Notice that some compe- 
ls nents support both a proxy interface and an authentica- 
bie interface, e.g: each of the Tenderers. 
[0084] An interface is simply a logical portion of the 
component and comprises a collection of callable meth- 
ods that can be called by other components. Whenever 

so an authenticator wants to communicate with a particular 
component, the authenticator looks for the pertinent in- 
terface on that component and communicates to it by 
calling the interface's methods. 
[0085] An authenticator verifies components and es- 

25 tablishes encrypted channels to oth er authenticators. ft 
also provides an encrypted channel service between 
components that process unencrypted data. The chan- 
nel can be used to negotiate arrays of session keys be- 
tween components to encrypt the main data. The 1A in- 

30 terface provides the authenticator with a list of compo- 
nents to verify, and a list of downstream components to 
continue the verification. The IAP proxy interface is a 
pass through interface for forwarding authentication in- 
formation between authenticators linked together by un- 

3s authenticated components. 

[0086] Within each authenticator, £„ represents an 
encryption/decryption key pair of the connection initiator 
and D n represents an encryption/decryption key pair of 
the connection receiver. 

40 [0087] The first authenticator A 1 can support multiple 
secondary authenticators (e.g. A^g) since it is used to 
verify two separate output chains (e.g. video and audio), 
[0088] The client creates the initial authenticator A, , 
and the IA interface of the first component (i.e. the De- 

45 Mux) is specified to the authenticator. In this example, 
the IA interface returns the following information to the 
authenticator: 

• A list of IA interfaces of downstream components; 
so . A list of lAProxy interfaces of downstream compo- 
nents (which only see encrypted data); 

• A list of dependent components on which to verify 
signatures; 

• Storage for the next authenticator link index (same 
ss authenticator can. be reused for multiple streams); 

and 

• Key session number for the authentication chain. 
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[0089] The authenticate {AO uses the client to verify 
the IA interface's address, then its dependent compo- 
nents, and recurses on each of its downstream IA inter- 
faces. Next the authenticator sets up an encrypted au- 
thenticated channel to the next authenticate r through 
each of the listed IAP interfaces. 
[0090] The JAP interface provides two methods to 
communicate to the next authenticator: 

• ReadData {buffer, length) 
» WriteData (buffer, length) 

[0091] Typically, the rendererwiSI supportthe IAP and 
IA interfaces. When the renderefs IAP interface is ref- 
erenced, it will create the next authenticator and proxy 
the SAP calls to it. The authenticators wilt then establish 
an authenticated encrypted communication channel. 
The authenticator is passed the IA interface of the Ten- 
derer so that it can begin a new authentication chain 
starting at the renderer. 

[0092] The authenticators can also provide methods 
to allow the components with IA interfaces to pass in- 
formation across Ihe authenticator channel. On the au- 
thenticator, this can include: 

• EncryptAndSand(linklD, [inj data) -send data to the 
; . next component. 

[0093] On the lA's interface that was passed to the 
authenticator, there can exist the following callbacks: 

• Decry ptAndReceive([out] data) - used to signal and 
' pass data to the receiving component; 

• " Tinkldentifier( [out] Sink ID } - passed to the IA inter- 

face to send. 

[0094] The send and receive methods can be used by 
the components to set up session keys for encrypting 
the main data. 

[0095] To simpfify the client, the authenticator can al- 
so provide the fotlowing simple encryption support: 

• CreateSessionf HANDLE [out], CLSfD drm- 
EncryptorlD ) - creates an encryptor and establish 
a session key; 

• EncryptData( HANDLE [in], BYTE* pin, BYTE* 
pOut); 

» DecryptData{ HANDLE [in], BYTE* pin, BYTE* 
pOut). . 

[0096] The authenticator would then persist the en- 
cryption object for the component. 

Network Embodiment - Case I 

[0097] One of the advantages of the architecture de- 
scribed above is that it can be utilized in connection with, 
and applied in the context of a network, such as the in- 



ternet. As an example, consider Fig. 6 which shows a 
system that is similar, in many respects, to the system 
shown and discussed in connection with Fig. 4. Like nu- 
merals from the Fig. 4 embodiment have been utilized, 
5 where appropriate (except that the designators in Fig. 6 
are in the form "6XX", whereas the designators in Fig. 
4 are in the form "4XX"). 

[0098] In this example, a remote device 624 is provid- 
ed and embodies software and hardware {collectively 
io designated at 61 7) that can be used to render content 
on the remote device. Exemplary remote devices can 
include handheld PCs, PDAs, USB speakers, IEEE 
1394 speakers and the like. Components such as the 
client 604, key manager 624, demu fttplexer 606 , decod- 
i5 ers 608a, 608b, encryptors 610a, 61 0b, application 612, 
renderers 614a, 614b, and one or more authenticators 
such as primary authenticator 618 and secondary au- 
thenticator 620, can resideon one side of a network con- 
nection such as on a host. Device 624 can then com- 
ae municate with the hostviaanetworkconnectionsothat 
it can render protected content from a trusted source for 
a user. 

[0099] In this example, remote device 624 Includes an 
authenticator 622 that can be set up and configured in 
25 a mannerthat is very simiiarto the way that the kernel 
mode authenticator was set up and configured above. 
[0100] That is, in this example, there is a logical con- 
nection between the authenticators on both sides of the 
network (e.g. authenticators 620 arid 622). This logical 
so connection Is authenticated and encrypted for ail of the 
reasons set forth above, The responsibility of the net- 
work renderer(s) is to communicate over the network 
and ascertain which components reside on remote de- 
vice 624. The renderer(s) then establish the authentica- 
35 tor on remote device 624, and establish a communica- 
tion channel between the two authenticators 620, 622. 
The channel can be used to set up keys between the 
encryptor 610a and the rendering hardware (61 7). 
[0101] Once the various components in the process- 
ed ing chain on each side of the network have been au- 
thenticated, the protected content can be provided to re- 
mote device 624 for rendering. 

Network Embodiment - Case II 

[01 02] Fig. 7 shows a system that Is slightly different 
from the system shown and described in Fig, 6. Here, 
remote device 724 embodies a purely hardware render- 
ing component 717. A software proxy 715 is provided 

so and can assist in the authentication process but may not 
necessarily be required to be trusted. Authentication 
can take place on the hardware itself as by, for example, 
providing PKI authentication support in the hardware, 
[0103] In this example, the network rendererfs) can 

55 map the authentication protocol on the left side of the 
network to the hardware authentication protocol in de- 
vice 724. This can make use of an authentication trans- 
lation module that resides in the software proxy 715. In 
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this case, then, the software proxy 715 will need to be 
trusted and verified. Alternatively, the hardware might 
be natively compatible with the authentication protocol 
on the left side of the network or, the hardware can con- 
tain a translation module to perform the mapping oper- s 
ation itself, thereby eliminating theneedto trust or verify 
the software on the device. 

[0104] This type of arrangement is advantageous 
from the standpoint of enabling third parties to write their 
own translator modules that can be employed on their io 
own remote devices. These modules can then perform 
the translation of the authentication protocol and, as a 
result, are not locked into any one authentication design. 
Third parties can also set up user mode authenticated 
on the left side of the network if, for example, their video « 
renderer needs to process unencrypted data. 
[0105] In addition, the above architecture is also ad- 
vantageous in that revocation iists can be transmitted 
over the various components, e.g. a server can send the 
revocation list to the ciient who can then send the list 20 
down the processing chain to the remote device. Con- 
sequently, any components that are revoked wili no 
longer be able to process the protected data. For exam- 
ple, a license that accompanies protected content might 
specify that the content requires a media path authen- 25 
ticator and, in addition, the device must periodically ac- 
cess a server to obtain a revocation list. The user can 
then, with their remote device, play content for a period 
of time after which their device will need to access the 
server to obtain the revocation list so that the device can so 
update their list of which components have been re- 
voked. 

Other Extensions and Advantages 

35 

[01063 The embodiments of Figs. 6 and 7 can be ex- 
tended such that the network renderer(s) is implement- 
ed as a broadcast renderer. For example, a broadcast 
service or server can set up and share encryption keys 
with a number of different hardware devices. Thebroad- -to 
cast renderer can then broadcast protected content to 
these devices and be assured that the content will re- 
main protected. 

[0107J Another advantage of the architecture is that 
data can be passed back and forth between the user 45 
and kernei modes as many times as necessary. This can 
be advantageous for such things as echo cancellation 
of audio data. That is, an audio renderer can go into the 
kernel and create another processing chain that goes 
back outto a user mode component and then back into so 
the kernel, 

Conclusion 

[0108] The methods and systems described above ss 
can provide improved methods and systems for 
processing renderable digital data. Some of the advan- 
tages of the above-described embodiments include, 



without limitation, that untrusted user mode components 
{decoders, video manipulations) and kernei mode com- 
ponents can be prevented from unauthorized access to 
protected content. Additionally, authorized components 
can be protected from being used to gain unauthorized 
access to protected content. Various third party compo- 
nents can be used in the processing chain and mecha- 
nisms can be provided to ensure that such components 
are trusted before they access protected content. Con- 
tent from multiple different sources, as well as multiple 
different types of content and DRW techniques can be 
easily incorporated into the system by virtue of a trans- 
lation process or translator modules. Various embodi- 
ments aiso permit protected content to be used across 
boundaries such as device and network boundaries, 
with an authentication process that is translatable 
across the boundaries. Further, revocation mechanisms 
(i.e. revocation lists) can be utilized to block compro- 
mised components from accessing protected content. 
The architecture can aiso enable secure communication 
channels to be established between the decoders and 
the rendering (i.e. display hardware). The architecture 
does not need prior knowledge of the component topol- 
ogy and be applied to complex structures since it follows 
the flow of data. 

[0109] Although the invention has been described in 
language specific to structural features and/or method- 
ological steps, it Is to be understood that the invention 
defined in the appended claims is not necessarily limited 
to the specific features or steps described. Rather, the 
specific features and steps are disclosed as preferred 
forms of implementing the claimed invention. 

Claims 

1 . A method comprising: 

receiving, with a client component, encrypted 
content that is to be protected during a render- 
ing process; 

receiving a manifest associated with the con- 
tent, the manifest specifying protected media 
path requirements forthe rendering process; 
verifying that the client component is a trusted 
component; 

creating a primary authenticated that can be 
used to authenticate one or more components 
downstream from the client component; 
articulating, to the primary authenticate r, one or 
more downstream components that need to be 
authenticated; 

authenticating one or more downstream com- 
ponents using the primary authenticates; 
creating at least one secondary authenticator; 
articulating to the secondary authenticator one 
or more downstream components that need to 
be authenticated; and 



12 



Ef> 1 376 302 A2 



authenticating one or more downstream com- 
ponents using the secondary authsnticator. 

2. The method of claim 1 further comprising determin- 
ing whether any digital rights management data as- 
sociated with the content needs to be translated to 
a form that can be understood by an authenticator's 
DRM system and, if so, effectuating translation of 
the digital rights management data. 

3. The method of ciaim 1 further comprising determin- 
ing whether any digital rights management data as- 
sociated with the content needs to be translated to 
a form that can be u nderstood by an authenticator's 
DRM system and, if so, effectuating translation of 
the digital rights management data by using a sep- 
arate translator module that is configured to trans- 
iate the digital rights management data. 

4. The method of claim 1 further comprising determin- 
ing whether any digital rights management data as- 
sociated with the content needs to be translated to 
a form that can be understood by an authenticator's 
DRM system and, if so, effectuating translation of 
the digital rights management data by using a sep- 
arate translator module that is configured to trans- 

: late the digital rights management data, the trans- 
lator module comprising a third party component. 

5. .. The method of claim 1 , wherein the act of articulat- 
ing to the primary authenticator is performed by the 
client component, responsive to being queried by 
the primary authenticator. 

6. The method of claim 1, wherein the act of verifying 
is performed by using a secure server. 

7. The method of claim 1 further comprising after cre- 
ating the secondary authenticator, verifying with the 
primary authenticator that the secondary authentic 



8. The method of claim 1 , wherein said acts of receiv- 
ing, verifying, creating., articulating, and authenti- 
cating are, at least in part, locally performed. 

S. The method of claim 1 further comprising after au- 
thenticating muitiple components, rendering the en- 
crypted content. 

10. The method of claim 1 further comprising after au- 
thenticating multiple components, effectuating ren- 
dering of the encrypted content on a remote device. 

11. A computing device programmed to implement the 
method of claim 1. 

12. One or more computer-readable media having 



computer-readable instructions thereon which, 
when executed by one or more processors, cause 
the one or more processors to: 

receive, with a client component, encrypted 
content that is to be protected during a render- 
ing process: 

receive a man ifest associated with the content, 
the manifest specifying protected media path 
requirements for the rendering process ; 
verify that the client component is a trusted 
component; 

create a primary authenticator and at least one 
secondary authenticator, the auihenticators be- 
ing configured to authenticate one or more 
components downstream from the client com- 
ponent; 

establish at least one secure communication 
channel between the authenticators; 
articulate, to the authenticators, one or more 
downstream components that need to be au- 
thenticated; 

authenticate one or more downstream compo- 
nents using the authenticators; and 
allow the one or more components to commu- 
nicate with one another using the secure com- 
munication channel. 

1 3. The one or more computer-readable media of claim 
1 2, wherein the instructions cause the one or more 
processors to determine whether any digital rights 
management data associated with the content 
needs to be translated to a form that can be under- 
stood by an authenticator's DRM system and, if so, 
effectuating translation of the digital rights manage- 
ment data. 

1 4. The one ormore computer-readable media of claim 
12, wherein the instructions cause the one or more 
processors to enable the one ormore components 
to set up session keys for use during the rendering 
process. 

15. The one ormore computer- readable media of claim 
12, wherein the instructions cause the one or more 
processors to enable the one ormore components 
to set up one or more banks of session keys for use 
during the rendering process, and cycle through the 
session keys during the rendering process. 

1 6. A comp uting device embodying the comp uter-read- 
abie medium of ciaim 12. 

17. A computing device comprising: 

memory ; 

one or more processors; 

i nstructions in the memory wh ich , when execut- 
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ed by the one or more processors, cause the 
one or more processors to: 

receive, with a client component, encrypt- 
ed content that is to be protected during a s 
rendering process; 

receive a manifest associated with the con- 
tent, the manifest specifying protected me- 
dia path requirements for the rendering 
process; to 
determine whether any digital rights man- 
agement data associated with the content 
needs to be translated to a form that can 
be understood by an auihenticator's DRM 
■system and, if so, effectuating, translation is 
of the digital rights management data ; 
verify that the client component is a trusted 
component; 

create a primary authentieator and at least 
one secondary authenticator, the authenti- 20 
cators being configured to authenticate 
one or more components downstream 
from the client component; 
establish at least one secure communica- 
tion channel between the authenticators; 2S 
articulate, to the authenticators, one or 
more downstream components that need 
to be authenticated; 

authenticate one or more downstream 
components using the authenticators; and so 
allow the one or more components to com- 
municate with one another using the se- 
cure communication channel, and allow 
the one or more components to set up ses- 
sion keys foruse during the renderingproc- 35 



18. A method comprising: 

establishing one or more paths of components 40 
that are to process and render digital content: 
receiving encrypted content that is to be proc- 
essed by the one or more paths, the encrypted 
content being subject to a license that defines, 
at least in part, how the encrypted data is to be 45 
processed; 

creating multiple authenticators to authenticate 
components along the one or more paths; 
providing a secure communication channel be- 
tween the authenticatprs; so 
determining whether any digital rights manage- 
ment data associated with the content needs to 
be translated to a form that can be understood 
by an auihenticator's DRM system and. if so, 
effectuating translation of the digital rights man- ss 
agement data by using a separate translator 
module that is configured to translate the digital 
rights management data ; 
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use the querying, with the authenticators, individual 

components of the one or more paths to ascer- 
tain which components the queried compo- 
nents pass data to ; 

authenticating, with the authenticators, the 
queried components and the components that 
the queried components pass data to; 
establishing encryption/decryption keys with 
multiple components of the one or more paths 
for the components to use to encrypt and de- 
crypt data, 

1 9. The method of claim 1 8, wherein the license spec- 
ifies one or more revocation lists that can be utilized 
to ascertain whether individual components have 
been compromised. 

20. The method of claim 18, wherein the license spec- 
ifies a level of security that is to be used to protect 
ihe encrypted content. 

21. The method of claim 18, wherein the act of estab- 
lishing the encryption/decryption keys comprises 
using the secure communication channel between 
the authenticators to establish the encryption/de- 
cryption keys. 

22. The method of claim 18, wherein the act of estab- 
lishing the encryption/decryption keys comprises 
establishing session-based keys. 

23. The method of claim 18 further comprising periodi- 
cally re-authenticating the components using the 
authenticators. 

24. The method of claim 18, wherein the act of creating 
the multiple authenticators comprises creating at 
least one user mode authenticator for authenticat- 
ing us er mode components , an d at least one kernel 
mode authenticator for authenticating kernel mode 
components. 

25. A computing device programmed to implement the 
method of claim 18. 

26. One or more computer-readable media having 
computer-readable instructions thereon which, 
when executed by one or more processors, cause 
the one or more processors to: 

establish one or more paths of components that 
are to process and render digital content- 
receive encrypted content that is to be proc- 
essed by the one or more paths, the encrypted 
content being subject to a license that defines, 
at least in part, how the encrypted data is to be 



create multiple authenticators to authenticate 
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components along the one or more paths; 
provide a secure communication channel be- 
tween the authenticators; 
query, with the authenticators, individual com- 
ponents of the one or more paths So ascertain 
which components the queried components 
pass data to; 

authenticate, with the authenticators, the que- 
ried components and the components that the 
queried components pass data to; and 
establish encryption/decryption keys with mul- 
tiple components of the one or more paths for 
the components to use to encrypt and decrypt 
data. 

27. The one or more computer-readable media of claim 
26, wherein the instructions cause the one or more 
processors to establish the encryption/decryption 
keys using the secure communication channel be- 
tween the authenticators. 

28. The one or more computer-readable media of claim 
26, wherein the instructions cause the one or more 
processors to establish the session-based encryp- 
tion/decryption keys using the secure communica- 
tion channel between the authenticators. 

29. A computing device embodying the computer-read- 
able media of claim 26. 



certain which components the queried 
components pass data to; 
authenticate, with the authenticators, que- 
ried components and, if possible, the com- 
ponents that the queried components pass 
data to; and 

establish encryption/decryption keys with 
multiple components of the one or more 
paths for the components to use to encrypt 
and decrypt data. 

31. The computing device of claim 30, wherein the li- 
cense specifies one or more revocation lists that 
can be utilized to ascertain whether individual com- 
ponents have been compromised. 

32. The computing device of claim 30, wherein identifi- 
cation information is passed up the a chain of en- 
crypted channels associated with the authentica- 
tors to allow for component verification, without re- 
quiring revocation lists to be propagated down the 
chain. 

33. The computing device of Claim 30, wherein the li- 
cense specifies a level of security that is to be used 
to protect the encrypted data. 

34. The computing device of claim 30, wherein the in- 
structions cause the one or more processors to es- 

' tablish session-based keys. 



30. A computing device comprising: 
memory; 

one or more processors; 

instructions in the memory which, when execut- 35 
ed by the one or more processors, cause the 
one or more processors to: 

establish one or more paths of components 
that are to process and render digital con- to 

receive encrypted content that is to be 
processed by the one or more paths, the 
encrypted content being subject to a li- 
cense that defines, at least in part, how the 45 
encrypted content is to be processed ; 
create multiple authenticators to authenti- 
cate components along the one or more 
paths, at least one of the authenticators 
comprising a user mode authenticator for so 
authenticating user mode components, 
and at least one otherof the authenticators 
comprising a kernel mode authenticator for 
authenticating kernel mode components; 
provide a secure communication channel ss 
between the authenticators; 
query, with the authenticators, individual 
components of the one or more paths to as- 



15. A method comprising: 

establishing one or more paths of components 
that are to process and render digital data, in- 
dividual components supporting one or more of 
an authenticable interface and a authentication 
proxy interface; 

creating a first authenticator to authenticate in- 
dividual components of the one or more paths; 
calling, with the first authenticator, one or more 
authenticabie interfaces on one or more re- 
spective components to ascertain components 
downstream from the components that are 
called; 

authenticating one or more downstream com- 
ponents using the first authenticator; 
for those components that support an authen- 
tication proxy interface and an authentication 
interface, creating a separate authenticator; 
establishing an encrypted channel between the 
first authenticator and one or more of the sep- 
arate authenticators; and 
authenticating additional components usingthe 
separate authenticator. 

36. The method of claim 35, wherein the one or more 
paths comprise an audio path and a video path. 
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37. The method of claim 35 further compriging provid- 
. ing, with the aufhenticators, an encrypted channel 

service between components that process unen- 
crypted data, 

5 

38. The method of claim 35 further comprising provid- 
ing, with the aufhenticators, an encrypted channel 
service between components that process unen- 
crypted data, and using the channel to negotiate ar- 
rays of session keys between components to en- io 
crypt and decrypt data. 

39. The method of ciaim 35 further comprising using 
one or more of the authentication proxy interfaces 

to authenticate between authenticated components t$ 
linked together by unauthenticated components. 

40. The method of claim 35, wherein the authenticable 
interface returns one or more of: a list of authenti- 

■ cation interfaces of downstream components, a list so 
of authentication proxy interfaces of downstream 
components, a list of dependent components on 
which to verify signatures, and key session number 
for the chain of authenticators. 

25 

41. The method of claim 35 further comprising provid- 
ing, with the authenticators, methods to allow com- 
ponents to pass information across the encrypted 
channel. 

42. The method of claim 35 further comprising translat- 
ing, if necessary, digital rights management data 
that is associated with the digital data and using the 
translated digital rights management data to protect 

the digital data during the rendering process. 35 

43. A computing device programmed to implement the 
method of claim 35. 

44. One or more computer-readable media having -to 
computer-readable instructions thereon which, 
when executed by one or more processors, cause 

the one or more processors to: 

establish multiple paths of components that are *b 
to process and render digital data, individual 
components supporting one or more of an au- 
thenticate interface and an authentication 
proxy Interface, the multiple paths comprising 
a video path for processing digits! video data, so 
and an audio path for processing digital audio 
data; 

translate, if necessary, digital rights manage- 
ment data that is associated with the digital da- 
ta and use the translated digital rights manage- ss 
ment data to protect the digital data during 
processing of the digital data; 
create a first authenticator to authenticate indi- 



vidual components of one or more of the paths; 
cail, with the first authenticate r, one or more au- 
thenticable interfaces on one or mare respec- 
tive components to ascertain components 
downstream from the components that are 
called; 

authenticate one or more downstream compo- 
nents using the first authenticator; 
for those components that support an authen- 
tication proxy interface and an authentication 
Interface, create a separate authenticator; 
establish an encrypted channei between the 
first authenticator and one or more of the sep- 
arate authenticators and use the channel to 
provide encryption/decryption keys to the com- 
ponents for use in encrypting and decrypting 
data; and 

authenticate additional components using the 
separate authenticator. 

45. The one or more computer- readable media of claim 
44, wherein the authenticable interface returns one 
or more of: a list of authentication interfaces of 
downstream components, a list of authentication 
proxy interfaces of downstream components, a list 
of dependent components on which to verify signa- 
tures, and key session number for the chain of au- 
thenticators. 

46. A computing device embodying the computer-read- 
able media of claim 44. 

47. A computing device comprising: 

memory; 

one or more processors; 
instructions in the memory which, when execut- 
ed by the one or more processors, cause the . 
one or more processors to; 

establish multipie paths of components 
that are to process and render digital data, 
individual components supporting one or 
more of an authenticable interface and an 
authentication proxy interface, the multiple 
paths comprising a video path for process- 
ing digital video data, and an audio path for 
processing digital audio data, the authen- 
ticable interface returning one or more of: 

a list of authentication interfaces of 

downstream components, 

a list of authentication proxy interfaces 

of downstream components, and 

a fist of dependent components on 

which to verify signatures, and 

key session number for the chain of 

authenticators; 
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translate, if necessary, digital rights man- 
agement data that is associated with the 
digital data and use the translated digital 
rights management data to protect the dig- 
ital data during processing of the digital da- s 
ta; 

create a first authentlcator to authenticate 
individual components of one or more of 
the paths; 

call, with the first authentlcator, one or 10 
more authenticate interfaces on one or 
more respective components to ascertain 
components downstream from the compo- 
nents that are called; 

authenticate one or more downstream " 
components using the first authenticator; 
for those components that support an au- 
thentication proxy interface and an authen- 
tication interface, create a separate au- 
thentlcator; 

establish an encrypted channel between 
the first authenticator and one or more of 
the separate authenticates and use the 
channel to provide encryption/decryption 
keys to the components for use in encrypt- 
ing and decrypting data: and 
authenticate additional components using 
the separate authenticator. 

48. A method comprising: 

establishing one or more paths of components 
that are to process and render digital data; 
receiving encrypted data that is to be proc- 
essed by the one or more paths, the encrypted 
data being subject to a license (hat defines how 
the encrypted data is to be processed; 
creating multiple authenticates to authenticate 
components along the one or more paths, at 
least one authenticator being created across a 
device boundary on a remote device : 
providing a secure communication channel be- 
tween the authenticators; 
querying, with the authenticators, individual 
components of the one or more paths to ascer- 
tain which components the queried compo- 
nents pass data to; 

attempting to authenticate, with the authentica- 
tors, the queried components and the compo- 
nents that the queried components pass data 
to; and 

establishing encryption/decryption keys with 
multiple components of the one or more paths 
for the components to use to encrypt and de- 
crypt data. 

49. The method of claim 43, wherein the license spec- 
ifies one or more revocation lists that can be utilized 



to ascertain whether individual components have 
been compromised. 

50. The method of claim 48, wherein the license spec- 
ifies a level of security that is to be used to protect 
the encrypted data. 

51. The method of claim 43, wherein the act of estab- 
lishing the encryption/decryption keys comprises 
using the secure communication channel between 
the authenticators to establish the encryption/de- 
cryption keys, 

52. The method of claim 4B, wherein the act of estab- 
lishing the encryption/decryption keys comprises 
establishing session-based keys. 

53. The method of claim 48 further comprising periodi- 
cally re-authenticating the components using the 

so authenticators. 

54. The method of claim 48, wherein the act of creating 
the multiple authenticators comprises creating at 
least one user mode authenticator for authenticat- 
es ing user mode components, and at least one kernel 

mode authenticator for authenticating kernel mode 
components. 

55. The method of claim 48 further comprising translat- 
30 ing, if necessary, DRM data that is associated with 

the encrypted data and using the translated DRM 
data to protect the encrypted data during the ren- 
dering process. 

35 56. One or more computer-readable media having 
computer-readable instructions thereon which, 
when executed by one or more processors, cause 
the processors to implement the method of claim 
48, 

40 

57. At least two computing devices configured to imple- 
ment the method of claim 48. 

58. A system comprising: 

one or more components configured to be used 
in a processing chain of components that proc- 
ess protected content that is to be rendered for 
a user; 

individual components supporting one or more 
of an authenticable Interface and a authentica- 
tion proxy interface; 

the authenticable interface being callable by an 
authenticator to return, to the authenticator: 

a list of authentication interfaces of down- 
stream components, 

a list of authentication proxy interfaces of 
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downstream components, and 

a list of dependent components on which 

to verify signatures; 

the authentication proxy interface providing 
methods for reading and writing data from and 
to authenticators. 

59. The system of claim 58, wherein the authenticate 
interface returns key session numbers for the chain 
of authenticators, 

60. The system of claim 58, wherein at least one com- 
ponent comprises a renderer. 

61 . The system of claim 58, wherein at least one com- 
ponent comprises a rendererthat supports both in- 
terfaces. 



the authenticate interface being callable 
by an authenticatorto return, to the authen- 
ticator, one or more of: 

a fist of authentication interfaces of 
downstream components, 
a list of authentication proxy interfaces 
of downstream components, and 
a list of dependent components on 
which to verify signatures; 

the authentication proxy interface providing 
methods .for reading and writing data from and 
to authenticators. 



62. The system of claim 58, wherein at least one com- 20 
ponent comprises a demultiplexer. 

63. The system of ciaim 58, wherein at least one com- 
ponent comprises a decoder. 

25 

64. The system of claim 58, wherein at least one com- 
ponent comprises a video decoder. 

65. The system of claim 58, wherein at least one com- 
ponent comprises an audio decoder. 30 

66. The system of claim 58, wherein at least one com- 
ponent comprises an encryptor. 

67. The system of claim 58, wherein at least one com- 35 
ponent comprises an audio encryptor. 

68. The system of claim 58, wherein at least one com- 
ponent comprises a video encryptor. 

69. The system of claim 58, wherein at least one com- 
ponent comprises a network renderer. 

70. A system comprising: 

4S 

multiple computing devices, ai least one com- 
puting device comprising a host computing de- 
vice and at least one computing device com- 
prising a remote computing device, individual 
computing devices comprising: so 



one or more components configured to be 
used in a processing chain of components 
that process protected content that Is to be 
rendered for a user ; 

individual components supporting one or 
more of an authenticabfe interface and a 
authentication proxy interface; 
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